In order to manage the functioning of an application, for example by forcing or directing its behaviour, a known method is to simulate a specific change to its environment, by injecting into it data which will simulate the occurrence of certain events. Such a practice can be useful for testing reactions from this application to certain situations, for example for its tuning or debugging. If one or more log files are available, storing events which occurred previously with a first application, it can be useful to be able to induce these same events with a new application.
Such a replay may be used, for example, to test the behaviour of this new application in order to establish what it would have done instead of the previous application. If this new application has been started or activated after the occurrence of these logged events, such a replay may enable this new application to be brought to a state where it has already taken these same events into account. Moreover, if this new application is restored beforehand from a restart point state corresponding to a fixed state from the former application, the replay of events logged in the former application after the restart point enables the restoration of the new application to a state corresponding to that of the former application after the occurrence of these events.
Among the events which occur in the operation of an application, those events which are initiated in an application by data coming from outside this applications may be qualified external, i.e. in particular coming from different hardware or software elements which it does not control. These may be, for example, a signal coming from an action on a keyboard, or a message arriving via a communication network.
In order to produce a simulation or a replay of external events with an application or one of its processes, a known method is actually to recreate the actions or messages which induced them, but this method involves significant resources and remains limited to relatively simple situations. Another known method is to edit the values of the memories which have to manage and store the results of these events to give them the values which they would have taken after the occurrence of these events. However, this method represents an additional complexity in the programming of this application, which is a source of costs and risks of error.
In addition, if an application is not designed from the start to produce such a record, it is difficult and costly to add such functionalities to it later, and this constitutes a significant risk of errors.
Some methods are also used by tuning, or “debugging” programs, which are used to force from outside the operation of an application. However, these methods more often than not require intervention within the computer system which executes the application, for example by changing or adding new kernel modules in the system. However, these system changes require specific system skills, and can induce heterogeneities between several computers of a network, which can be a source of errors and instabilities. More often than not, these disadvantages greatly limit the use of the record and replay principle, in particular to tuning tasks or isolated configurations, and are unacceptable for configurations which are both extensive and stressed in exploitation conditions. In particular while running the master application, the logging operations represent a workload for the operational node, and can be the cause of a fall-off in performance due to the action of the intermediate application.